1. Field of Invention
The invention relates generally to methods and apparatuses for locally invoking objects in distributed object systems. More particularly, the invention relates to methods and apparatuses for efficiently enabling local object references to be created and invoked within a distributed object system.
2. Description of the Relevant Art
A computing environment in which objects are located on different computers linked by a network is typically referred to as a client-server computing environment. Some computers act as providers of services or add functionality to other computers. The providers of service or functionality are known as “servers” and the consumers of the service or functionality are called “clients.” The client-server model may also be generalized to the case where distinct programs running on the same computer are communicating with one another through some protected mechanism and are acting as providers and consumers of services or functionality.
Attempts to provide such a distributed system have been made using object-oriented methodologies that are based upon a client-server model in which server objects provide interfaces to client objects that make requests to server objects. Typically, in such a distributed system, the servers are objects consisting of data and associated methods. The client objects obtain access to the functionalities of the server objects by executing calls on them, calls which are mediated by the distributed system. When the server object receives a call, it executes the appropriate method and transmits the result back to the client object. The client object and server object communicate through an Object Request Broker (ORB) which is used to locate the various distributed objects and to establish communications between objects. Distributed objects may exist anywhere in a network as, for example, in the address space of the client, in multiple address spaces on the client machine, and in multiple machines across the network.
The software industry has responded to the need for a distributed object technology by forming the Object Management Group (OMG). The goal of the OMG is to define the Object Management Architecture (OMA), which has four major components: the Object Request Broker (ORB), Object Services, Common Facilities, and Application Objects. The Object Request Broker provides basic object communications and management services, thereby forming the basis of a distributed object system. A standard for an Object Request Broker is contained in the Common Object Request Broker Architecture (CORBA) specification from the OMG, Revision 2.0, updated July 1996, which is incorporated herein by reference in its entirety. The CORBA specification generally defines an object model on top of a programming language, e.g., C++or Java™ (developed by Sun Microsystems, Inc. of Palo Alto, Calif.), in which server objects have references which may be exported to clients. Within the object model, clients and servers are “roles,” and are typically not mutually exclusive tasks for a single program. Instead, a program may be both a client and a server.
Within an object-based system such as a distributed object system, a single server object may be accessed by multiple clients. FIG. 1a is a diagrammatic representation of two clients which are arranged to invoke a single server object in accordance with prior art. A first client 104 is essentially a program which is running in a first process 108. First client 104 may invoke a server object 112 that is running in a second process 116. A non-local invocation may be performed on object 112 by first client 104. Object 112 may be an object defined under the CORBA specification. When invoked, object 112 is arranged to service a request from first client 104. A request from first client 104 is typically marshaled for transport to object 112, and unmarshaled once it is received by object 112. A second client 120, which is within second process 116 and, hence, is in the same process as object 112, may also invoke object 112. An invocation on object 112 by second client 120 is a local invocation.
Since first client 104 and second client 120 are arranged such that they may invoke object 112 at substantially the same time, it is generally necessary to synchronize calls to object 112. In other words, calls to object 112 must typically be synchronized in order to prevent threads associated with first client 104 and second client 120 from operating concurrently on object 112. Calls to object 112 may be synchronized by object managers included within a distributed object system, as will be appreciated by those skilled in the art. Synchronization processes which are used to synchronize calls to object 112 from first client 104 and second client 120 are often expensive and time-consuming, as synchronization processes require substantial computational overhead and processing.
Object 112 may generally support a variety of different features, e.g., object 112 may create object references outside of second process 116. In general, an object reference 124 may be created by object 112 such that object reference 124 is associated with client 104. Reference 124 includes a pointer 126 to a client representation reference 128 which, in turn, includes a pointer to object 112. Reference 124 is utilized by client 104 in order to invoke object 112. As will be appreciated by those skilled in the art, reference 124 may remain constant. However, object 112, which services client 104, may change over time, e.g., object 112 may have a life span which is less than the life span of second process 116. Hence, “invoking” on reference 124 may cause a new object to be created, if object 112 no longer exists. By way of example, object 112 may represent any row in a data base, and reference 124 may refer to a particular row in the data base. As such, reference 124 is essentially “bound” to an object that represents a particular row in the data base. Therefore, each time reference 124 is invoked, an associated object must generally be “looked up,” or otherwise located. Whenever the row referred to by reference 124 is referenced, a new object which represents the row is created in the event that object 112 is no longer alive.
First process 108 and second process 116 are often separated by a computer network. Since the overhead associated with network communications is often relatively high, the overhead associated with synchronizing calls to object 112, as well as the overhead associated with locating object 112 based on reference 124, is relatively insignificant when compared to the overhead associated with network communications.
An object within a process may also be invoked by multiple clients which are within the same process. Specifically, an object may be such that it is accessible only to clients which are within the same process, e.g., the server process, as the object. An object that is accessible only to clients within the same process may be a locality-constrained object, which is an object associated with portable object adapters (POAs) as specified in standards issued by the OMG, e.g., OMG document orbos/97-04-14, chapter 3, which is incorporated herein by reference in its entirety. With reference to FIG. 1b, the invocation of an object by clients within the same process as the object will be described in accordance with prior art. A servant object 154 is present within a process 158, and is unable to create object references outside of process 158. These object references are then considered to be locality-constrained, as they are bound to the process that created them. A number of clients 162, each of which has an associated object reference (not shown) relating to object 154, within process 158 may simultaneously attempt to invoke object 154.
When client 162a invokes object 154, invocation requests associated with client 162a and object 154 are typically marshaled for transport to object 154 and unmarshaled after they are received by object 154. An invocation request may be marshaled for transport to object 154, and unmarshaled for receipt by object 154. Such marshaling and unmarshaling is time-consuming and, as a result, affects the performance of an invocation performed on object 154.
Clients 162 are also often “synchronized” such that only one client, e.g., client 162a, may access object 154 at one time. However, as a process typically has only a single, associated thread, process 158 and, hence, clients 162, have only a single associated thread. As such, when object 154 is accessible only to clients 162 within the same process 158, attempts at synchronization are both time consuming and unnecessary.
For an object which is accessible only to clients that are local to the object, i.e., an object which can be accessed only by clients which share the same process as the object, implementing and invoking the object in the same manner as an object which may be locally and non-locally invoked is inefficient and may result in significant overhead. Specifically, when a particular object in a process is known to be unable to create object references outside of the process, providing the object with capabilities and features associated with object references created outside of the process may prove to be both inefficient and expensive. There is a trade-off between the features associated with the object and the speed at which the invocation of the object can occur. By way of example, for an object which can only be locally invoked, thread synchronization, as well as marshaling and unmarshaling locally invoked objects, is both time-consuming and inefficient when an object may only be locally invoked. Therefore, what is desired is a fast, efficient method for locally invoking an object from within the same process as the object, when the object is not arranged to create references outside of the process.